快速解答： 功能開發不是一個人的獨角戲,它包含機會驗證、用戶研究、設計、開發、測試、上線六種截然不同的工作類型。多數新手 PM——不管是團隊裡的新人,還是自己用 Claude 打造產品的獨立開發者——最容易犯的錯,是還沒搞懂「有哪些工作要做」,就急著問「誰要做」。這篇文章會帶你先定義工作內容,再教你怎麼用 DRI(直接負責人)框架和 Claude AI,把每一項工作對應到對的人,或是對應到你自己。

你是不是也曾經接到一個功能任務,連工作範圍都還沒搞清楚,就開始問「這個功能誰負責」?

先停一下。

如果你剛開始學寫程式,或是正在用 Claude 生態系從零打造自己的軟體產品,你可能會覺得「分工」是大公司才需要煩惱的事。畢竟,你一個人,還分什麼工?

但事實恰恰相反。分工的本質不是「誰跟誰合作」,是「把工作看清楚」。 就算你是一人團隊,你也在同時扮演 PM、設計師、工程師這三個角色。搞不清楚每個角色該做什麼,你就會在不知不覺中,漏掉某個關鍵步驟——然後在專案後期,付出遠比現在更高的代價。

這篇文章,會先帶你走一遍功能開發的完整工作內容,再教你怎麼把這些工作,對應到團隊裡的人,或是對應到你自己身上。

功能開發到底包含哪些工作?

功能開發,不是「想到點子就開始寫程式」這麼簡單。

它至少包含六種工作類型:機會驗證、用戶研究、設計、開發、測試、上線。每一種,都需要不同的技能和資源。

• 機會驗證——確認這個功能值不值得做
• 用戶研究——確認用戶是不是真的想要
• 設計——把驗證過的問題,轉化成具體解法
• 開發——把設計實際寫成程式碼
• 測試——確保功能上線前不會出包
• 上線——讓功能安全、順利地推到用戶面前

為什麼跳過某個步驟,功能就容易失敗?

多數新手最常跳過的,是最前面的機會驗證。

理由很直接:訪談用戶很麻煩,叫 Claude Code 生成程式碼只要幾秒鐘。但如果你打造出來的東西沒人想用,再乾淨的程式碼也只是白工。

Amazon 的 Fire Phone 就是一個活生生的例子。它策略契合、商業價值都到位,卻缺了最關鍵的一塊——用戶價值。用戶不買單,一年後這款手機就停產了。反過來,Google Photos 同時具備策略契合、商業價值、用戶價值三個要素,結果在 Google Play 上累積超過 50 億次下載,Apple App Store 評分高達 4.7 顆星。

差別不在技術能力,在於有沒有走完每一個該走的步驟。

機會驗證階段,誰該做什麼?

機會驗證,是功能開發的地基。地基歪了,上面蓋的東西再漂亮也會倒。

這個階段,通常涵蓋四件事:確認策略契合、精煉用戶價值、釐清商業價值、建立團隊共識。

用戶價值精煉:怎麼用 Claude AI 加速訪談流程?

用戶價值精煉,靠的是真實訪談,不是憑感覺猜測。

業界經驗法則是:平均訪談 6 個人,就能掌握用戶的大致想法。但要湊到 6 個合格對象,你可能需要主動接觸將近 90 個人——這還沒算上設計訪談問題、整理逐字稿的時間。

這正是 Claude AI 能幫上忙的地方。你可以請 Claude 幫你依照屬性分群名單、草擬邀約訊息、準備訪談大綱,訪談結束後再把逐字稿丟給它,整理出關鍵發言與矛盾之處。但真正聽懂用戶語氣裡的猶豫,追問一個意外冒出來的新問題——這是只有你在現場才能捕捉到的東西。

商業價值精煉:怎麼用漏斗分析找出真正值得解決的問題?

主管的估計常常是錯的。不是因為主管不專業,而是那個數字,往往是根據不完整的資訊拍腦袋算出來的。

商業價值精煉的做法,是透過漏斗分析,找出用戶流失最嚴重的環節,再用內部或外部的代理指標,估算實際可達成的影響力。Lyft 團隊發現司機取消行程的關鍵環節後,用一個「不同功能、類似情境」的代理指標,估算出新功能能把取消率降低 1.5%——這個機會,後來變成了廣受歡迎的「目的地模式」功能。

Claude AI 最能幫上忙的地方,是資料整理與模式辨識。 把用戶行為數據丟給它,請它幫你彙整每個步驟的轉換率、標示異常的流失點。但判斷哪個流失點才是真正值得解決的問題,還是得靠你對業務脈絡的理解。

建立團隊共識:誰該負責跟利害關係人溝通?

驗證做得再好,不溝通照樣白做。

這個步驟通常由 PM 主導——因為 PM 手上握有完整的機會脈絡。你需要分清楚兩種會議:專案更新,對齊核心團隊(設計師、工程師);產品審查,對齊領導層,拿到明確的核准。

一個實用的判斷原則是:你應該是這場會議裡最資淺的人。只邀請真正受影響的關鍵領導者,把會議控制在最小規模。

設計階段,誰該做什麼?

機會驗證完成後,下一個工作是設計——把驗證過的問題,轉化成具體解法。這個階段分成三步:發散、收斂、核准。

發散:PM 該提供限制,不是自己下場設計

新手最容易掉進兩個極端:把設計整個丟給設計師憑空發想,或是自己跳下去指導棋。兩者都行不通。

PM 真正該做的,是把驗證過的策略契合、用戶價值、商業價值,轉化成明確的限制條件,交給設計團隊。 限制不是牢籠,是護欄——它讓團隊能把創意能量,集中在真正有意義的空間裡。

這一步,Claude AI 能幫你根據限制條件生成初步點子、把腦力激盪結果分群整理,大幅加速發散階段的效率。Airbnb 團隊就是用這套流程,把 17 個解法點子收斂成 6 個群組,再進一步篩選成 9 個值得測試的方案。

收斂:誰該主持原型測試?

收斂靠的是兩件事:優先排序與原型測試。優先排序時,PM 該主動拉工程團隊一起評估可行性和可執行性;原型測試時,PM 很適合跟設計師一起主持訪談,因為你對用戶脈絡的理解,能幫忙判斷用戶反應背後真正的原因。

在設計階段抓到問題,遠比在開發階段便宜。改一張草圖只要幾分鐘,改一段已經寫好的程式碼,代價是重寫、重新測試、重新部署。

設計核准:誰該拍板?

設計核准包含兩個里程碑:設計審查(對齊設計領導層)與 PRD 更新(鎖定核准與實作細節)。這裡的核心目標,是「盡可能為專案去風險」——多數團隊需要兩到三輪迭代,才能真正拿到核准。

怎麼把團隊對應到這些工作?

走到這一步,你應該已經清楚知道有哪些工作要做。現在,才是真正該問「誰來做」的時候。

為什麼不同公司的分工方式差這麼多?

一個很現實的問題是:你的分工方式,取決於公司的規模和成熟度。

在 Airbnb 或 Salesforce 這種大型科技公司,你可能會看到 Engineering Manager 和 Technical Lead 各自負責不同的工程工作。但如果你在一家 A 輪新創,一個人可能同時扛下 EM 和 TL 的職責——甚至有些工作,例如產品行銷,在你的組織裡根本沒有明確的擁有者。

這正是「團隊對應」這個步驟存在的意義:定義清楚「什麼」工作需要完成,以及「誰」該負責。

業界的分工基準是什麼?

根據 Reforge 專家在 B2C 與 B2B、早期到成熟公司的經驗,大致的分工基準是這樣的:

• 定義里程碑——由 PM 主導,工程提供輸入
• 撰寫技術規格、估算工時、工程師配置——由工程團隊主導
• 專案啟動會議——由 PM 主持
• 建置功能(寫程式碼)——由工程師主導
• 管理利害關係人溝通、解決開發瓶頸——通常由 PM 負責
• 風險管理——PM 主導,因為他們最了解時程、里程碑與依賴關係的全貌

你可以把這份基準當成起點假設,再拿去跟你的技術主管或工程師確認:「這個假設在我們團隊成立嗎?」

沒有人負責這項工作,該怎麼辦?

這是新手最容易誤判的地方——發現工作缺口,就直接假設自己該全部扛起來。

正確的做法,是先問自己兩個問題:技能重疊和工作範疇。

技能重疊,問的是「我的技能,跟做好這件事需要的技能,重疊程度有多高?」——例如產品經理跟市場推廣(GTM)、客服支援(Ops)之間的技能重疊度就相當高,因為都需要理解用戶的聲音、產品的價值,以及怎麼把價值傳達出去。但工程,通常是技能重疊最低的領域——多數非技術 PM 不具備寫程式的能力,這就是你該畫下界線、暫停工作,直到找到合適人選的時候。

工作範疇,問的是「這件事影響的範圍,是只限於你的專案,還是牽涉整個部門甚至整個公司?」你最適合承接的,是落在專案範圍內、又跟你技能高度重疊的工作。超出這個交集的,該做的是升級(escalate),而不是自己硬扛。

前 Apple 工程專案經理 Gloria Lin 曾這麼形容 DRI(直接負責人)模式的價值:「它幫助團隊在某個環節出現缺口時,有人能主動指出來、把事情推向完成,並為策略性決策負責。」

怎麼用 Claude AI 整理團隊產能與工作需求?

不管你是團隊裡的 PM,還是一個人用 Claude 打造產品的獨立開發者,這一步都能靠 Claude AI 加速。

把你團隊成員的技能、可用時間,以及功能開發需要的各項工作,丟給 Claude,請它幫你交叉比對出可能的資源缺口。它也能幫你把 DRI 分配表格式化、草擬需要升級溝通的內容草稿。但真正決定「這個缺口該由誰補上」的判斷,終究得靠你自己來下。

如果你是獨立開發者,這一步的意義稍微不同——你不是在找「誰來補位」,而是在確認:哪些工作我可以自己來,哪些工作(通常是需要深厚工程或設計專業的部分)該交給 Claude Code 或 Claude Design 這類工具輔助完成。

分工時最容易踩的坑有哪些?

知道流程還不夠,實際執行時,新手常常會掉進這幾個坑:

• 還沒定義清楚工作內容,就急著問「誰負責」——順序反了,你會漏掉隱形的工作
• 發現缺口,就直接自己扛下所有工作——這會讓你沒有時間專注在真正該做的事情上
• 忽略技能重疊與工作範疇的判斷——導致你接下了自己根本做不好的工作
• 沒有明確指定 DRI——結果每個人都以為對方會做,實際上沒有人真的在做
• 跳過驗證直接分工——工作內容定義得再細,如果機會本身沒驗證過,分工也只是在浪費資源

這些陷阱背後,其實只有一個共同根源:把「應該有人在做」,當成了「真的有人在做」。

先懂工作,才能懂團隊

功能開發從來不是一個人的獨角戲,就算你真的是一個人在做。

機會驗證、用戶研究、設計、開發、測試、上線——每一項工作,都需要不同的技能和判斷。Claude AI 能在每個階段幫你分擔資料整理的工作——訪談分群、漏斗彙整、腦力激盪草稿、產能比對。但決定「這個問題值不值得解決」「這項工作該由誰負責」「這個設計是不是真的可行」的人,永遠是你。

下次你接到一個功能任務,別急著打開 Claude Code 開始寫程式。先問自己:我搞清楚所有該做的工作了嗎?我知道誰該負責每一項工作了嗎?如果沒有人負責,我是該自己扛下來,還是該升級求助?

最好的團隊分工,從來不是憑感覺分配的。是從搞懂工作本身開始的。

常見問題

我是一個人用 Claude 打造產品,還需要做團隊對應嗎?
需要。就算只有你一個人,你依然同時扮演 PM、設計師、工程師的角色。搞清楚每個角色該做什麼工作,能幫你避免漏掉關鍵步驟,也能幫你判斷哪些工作適合自己動手,哪些該交給 Claude Code 或 Claude Design 輔助完成。

團隊分工基準適用於所有公司規模嗎?
基準只是起點,不是標準答案。大型科技公司通常有明確的 Engineering Manager 和 Technical Lead 分工,而早期新創可能一個人同時扛下多項職責。你應該把基準當作假設,再跟團隊成員逐一確認實際情況。

發現工作缺口時,我該自己扛下來嗎?
先問自己兩個問題:你的技能跟這項工作需要的技能重疊度高不高?這項工作只影響你的專案,還是牽涉整個部門或公司?只有同時符合「高技能重疊」與「專案範圍內」的工作,才適合你自己接手,其餘的應該升級求助。

跳過機會驗證,直接進行團隊分工,風險是什麼?
最大的風險是,就算分工再清楚,團隊投入的每一分鐘,都建立在一個未經檢驗的假設上——如果這個功能本身不值得做,再完美的分工也只是在浪費資源。

Claude AI 在團隊對應這個環節,最能幫上什麼忙?
它最擅長資料整理與交叉比對——把團隊成員的技能、時間,跟功能開發所需的各項工作進行配對,快速標示出可能的資源缺口。但最終判斷「誰該負責什麼」,仍然需要你對團隊與業務脈絡的理解。